|
|
|
|
|
|
|
OOP bring an anti-analysis attitude with them into object-oriented projects. This is the favored approach for many programmers because each programmer decides for himself how the application will work and avoids becoming caught up in analysis paralysis. If there is a team of developers, they divide up the user requirements document, code in isolation, and come back together to argue over who is wrong or right, what should be hacked from the current release, and so on. Because of the complexity of user requirements, such an approach is prone to errors, and the user typically ends up with a system he did not ask for or want. To accommodate (or out of sympathy for) the developers (who probably stayed up all night for a whole week), the user says something like Yeah, this looks okay. I guess I can do my work with this. The application is seldom used or is full of major bugs; eventually, the user returns to the manual way of doing business. |
|
|
|
|
|
|
|
|
Note
Analysis paralysis is a phase in a project when problem analysis seems to be performed endlessly and without hope of finding a solution. |
|
|
|
|
|
|
|
|
|
The same thing applies when you try to implement OOP without doing the necessary analysis. In general, analysis helps find a solution to a business problem; someone's dream can become a high-level, often user-friendly model that evolves into an application. Using a methodology or carrying out some goal(s) to cultivate this evolutionary process is crucial. Perhaps the most widely used methodology is the Objectory method introduced by Ivar Jacobson. It's also generally known as object-oriented software engineering (OOSE). With it, you initiate a process of identifying what the current problem is and then help the user identify how she sees herself using the proposed application. |
|
|
|
|
|
|
|
|
New Term: Methodology is an organized, disciplined system for doing something in an orderly manner. It's the implementation of a body of methods to achieve a measurable goal. |
|
|
|
|
|
|
|
|
Pivotal Team Roles in Object-Oriented Analysis |
|
|
|
|
|
|
|
|
To effectively use OOA to create a solid, easily extensible system using Visual Basic, you should have an understanding of the overall approach to the project. This means that every activity you expect to undertake in creating a Visual Basic application should be reasonably thought out beforehand. That is, you as a Visual Basic developer must accept that you will usually (but not always) wear many hats on a typical development project. These hats (or roles) should be identified and specified. Further, in performing these roles, you will perform tasks related to each role. These tasks, too, must be identified and quantified. |
|
|
|
|
|